System, method and computer program product for sending unwanted activity information to a central system

ABSTRACT

A system, method and computer program product are provided for sending, to a central system, information associated with unwanted activity. In use, information associated with unwanted activity is identified utilizing a plurality of different types of security systems. Further, the information is sent to a central system.

FIELD OF THE INVENTION

The present invention relates to identifying unwanted activity, and moreparticularly to security systems utilized for identifying unwantedactivity.

BACKGROUND

Traditionally, security systems have been utilized for identifyingunwanted activity (e.g. malware, etc.). In general, different securitysystems have employed various techniques for identifying unwantedactivity. Just by way of example, virus scanners oftentimes employscanning techniques, whereas firewalls usually employ filteringtechniques. However, traditional security systems have customarilyexhibited various limitations.

For example, traditional security systems have each been incapable ofindependently determining sufficient identifiable information associatedwith unwanted activity, such as a source of the unwanted activity, atechnique utilized by the unwanted activity, etc. As another example,traditional security systems have conventionally been isolated from oneanother, thus preventing any sharing of information associated withidentified unwanted activity. There is thus a need for addressing theseand/or other issues associated with the prior art.

SUMMARY

A system, method and computer program product are provided for sending,to a central system, information associated with unwanted activity. Inuse, information associated with unwanted activity is identifiedutilizing a plurality of different types of security systems. Further,the information is sent to a central system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a network architecture, in accordance with oneembodiment.

FIG. 2 shows a representative hardware environment that may beassociated with the servers and/or clients of FIG. 1, in accordance withone embodiment.

FIG. 3 shows a method for sending, to a central system, informationassociated with unwanted activity, in accordance with one embodiment.

FIG. 4 shows a system for sending, to a central system, informationassociated with unwanted activity, in accordance with anotherembodiment.

FIG. 5 shows a method for reacting to an event, decision and/or alert,in accordance with yet another embodiment.

FIG. 6 shows a system for sending information associated with unwantedactivity from a central system to a super system, in accordance withstill yet another embodiment.

FIG. 7 shows a method for configuring a device, in accordance with stillyet another embodiment.

DETAILED DESCRIPTION

FIG. 1 illustrates a network architecture 100, in accordance with oneembodiment. As shown, a plurality of networks 102 is provided. In thecontext of the present network architecture 100, the networks 102 mayeach take any form including, but not limited to a local area network(LAN), a wireless network, a wide area network (WAN) such as theInternet, a peer-to-peer network, a personal area network (PAN), etc.

Coupled to the networks 102 are servers 104 which are capable ofcommunicating over the networks 102. Also coupled to the networks 102and the servers 104 is a plurality of clients 106. Such servers 104and/or clients 106 may each include a desktop computer, lap-topcomputer, hand-held computer, mobile phone, personal digital assistant(PDA), peripheral (e.g. printer, etc.), any component of a computer,and/or any other type of logic. In order to facilitate communicationamong the networks 102, at least one gateway 108 is optionally coupledtherebetween.

FIG. 2 shows a representative hardware environment that may beassociated with the servers 104 and/or clients 106 of FIG. 1, inaccordance with one embodiment. Such figure illustrates a typicalhardware configuration of a workstation in accordance with oneembodiment having a central processing unit 210, such as amicroprocessor, and a number of other units interconnected via a systembus 212.

The workstation shown in FIG. 2 includes a Random Access Memory (RAM)214, Read Only Memory (ROM) 216, an I/O adapter 218 for connectingperipheral devices such as disk storage units 220 to the bus 212, a userinterface adapter 222 for connecting a keyboard 224, a mouse 226, aspeaker 228, a microphone 232, and/or other user interface devices suchas a touch screen (not shown) to the bus 212, communication adapter 234for connecting the workstation to a communication network 235 (e.g., adata processing network) and a display adapter 236 for connecting thebus 212 to a display device 238.

The workstation may have resident thereon any desired operating system.It will be appreciated that an embodiment may also be implemented onplatforms and operating systems other than those mentioned. Oneembodiment may be written using JAVA, C, and/or C++ language, or otherprogramming languages, along with an object oriented programmingmethodology. Object oriented programming (OOP) has become increasinglyused to develop complex applications.

Of course, the various embodiments set forth herein may be implementedutilizing hardware, software, or any desired combination thereof Forthat matter, any type of logic may be utilized which is capable ofimplementing the various functionality set forth herein.

FIG. 3 shows a method 300 for sending, to a central system, informationassociated with unwanted activity, in accordance with one embodiment. Asan option, the method 300 may be carried out in the context of thearchitecture and environment of FIGS. 1 and/or 2. Of course, however,the method 300 may be carried out in any desired environment.

As shown in operation 302, information associated with unwanted activityis identified, utilizing a plurality of different types of securitysystems. In the context of the present description, the unwantedactivity may include any activity that is determined to be unwanted orat least potentially unwanted. For example, the unwanted activity mayinclude malware (e.g. a virus, a Trojan, a worm, etc.), spyware,unsolicited electronic messages, etc. and/or any combination thereof.

Optionally, the activity may be determined to be unwanted utilizing thesecurity systems. Just by way of example, the security systems maycompare the activity to known unwanted activity, monitor the activity,perform a behavioral analysis with respect to the activity, apply a ruleto the activity, etc. In this way, the security systems may be utilizedto detect the unwanted activity, and possibly confirms its unwantedstatus.

In the context of the present description, the information associatedwith the unwanted activity may include any information capable ofidentifying, characterizing, and/or describing, etc. the unwantedactivity, and/or any other information that is relevant to the unwantedactivity. For example, in one possible embodiment, the information mayindicate a source of the unwanted activity. Thus, such information mayinclude an internet protocol (IP) address of the source, a uniformresource locator (URL) of the source, etc. In other various examples,the information may include a time in which the unwanted activity wasdetected, code utilized by the unwanted activity, a manner in which theunwanted activity was received (e.g. by a device on which such unwantedactivity was detected, etc.), a manner in which the unwanted activityexecutes (e.g. utilizing a trusted process, etc.), a type of theunwanted activity (e.g. virus, a worm, etc.), etc.

In another embodiment, the information associated with the unwantedactivity may include a decision made in response to the unwantedactivity, such as in response to detection of the unwanted activity. Asan option, the decision may be to block execution of the unwantedactivity, quarantine the unwanted activity, remove (e.g. uninstall,etc.) the unwanted activity, etc. Further, the decision may be madebased on rules, a behavioral analysis, etc. To this end, the informationmay optionally indicate the decision made with respect to the unwantedactivity.

In yet another embodiment, the information associated with the unwantedactivity may include an alert. The alert may include a notification ofthe unwanted activity, for example. Optionally, the alert may identifythe unwanted activity.

Accordingly, the information associated with unwanted activity mayoptionally be identified based on the detection of the unwantedactivity. In one embodiment, the information may be identified byextracting the information from code utilized by the unwanted activity.In another embodiment, the information may be identified by monitoringand/or analyzing the unwanted activity. Of course, however, theinformation may be identified in any manner that utilizes the pluralityof different types of security systems.

With respect to the present description, the security systems mayinclude any systems capable of identifying information associated withunwanted activity. In various embodiments, the security systems mayinclude a firewall, an intrusion prevention system, an anti-spywaresystem, a virus scanner, a system for identifying unsolicited electronicmessages, a rootkit detection system, and/or an anti-phishing system,etc. Furthermore, the security systems may be different in thetechniques utilized for identifying unwanted activity (e.g. virusscanning, filtering, etc.), the type of unwanted activity identified,and/or in any other manner.

As an option, the security systems may be located (e.g. installed, etc.)on a client system. For example, such client system may include any ofthe devices described above with respect to FIGS. 1 and/or 2. Thesecurity systems may also be located on a network, such as any of thenetworks described above with respect to FIG. 1. Moreover, the securitysystems may be integrated, and therefore in communication with oneanother.

It should be noted that, in one embodiment, the unwanted activity mayinclude multiple instances of the same or different unwanted activity,where each instance is associated with a different security system. Inthis way, the identified information that is associated with theunwanted activity may be associated with different instances of unwantedactivity.

With continuing reference to FIG. 3, the information is sent to acentral system. Note operation 304. In the context of the presentdescription, the central system may include any central system capableof receiving the information. For example, the central system mayinclude any of the devices described above with respect to FIGS. 1and/or 2.

Further, the information may be sent utilizing an electronic message, areport, etc. In one embodiment, the information may be sent to thecentral system by the client system on which the security systems arelocated. For example, the information may be sent by a client systemwhich identified the information. As noted above, such client system maybe located on a network.

In another embodiment, the central system may also be located on thenetwork and/or in communication with the network. Thus, the informationmay optionally be sent to the central system over at least one network.Of course, however, the information may also be sent to the centralsystem in any manner.

As an option, the information may be correlated prior to sending theinformation to the central system. Correlating the information mayinclude aggregating portions of the information that are the same, forexample. As another example, the information may be correlated bygrouping portions of the information that are associated with the sameinstance of unwanted activity.

More illustrative information will now be set forth regarding variousoptional architectures and features with which the foregoing frameworkmay or may not be implemented, per the desires of the user. It should bestrongly noted that the following information is set forth forillustrative purposes and should not be construed as limiting in anymanner. Any of the following features may be optionally incorporatedwith or without the exclusion of other features described.

FIG. 4 shows a system 400 for sending, to a central system, informationassociated with unwanted activity, in accordance with anotherembodiment. As an option, the system 400 may be implemented to carry outthe method 300 of FIG. 3. Of course, however, the system 400 may beimplemented in any desired environment. It should also be noted that theaforementioned definitions may apply during the present description.

As shown, a client system 402 is in communication with a central system404. While not shown, it should be noted that multiple different clientsystems may also be in communication with the central system 404. As anoption, the client system 402 may communicate with the central system404 via a network (not shown). Of course, however, the client system 402may communicate with the central system 404 in any desired manner.

The client system 402 includes a plurality of different securitysystems. As shown by way of example, the security systems may include arootkit detection security system, a firewall, a host intrusionprevention system, an anti-phishing system, an unsolicited electronicmessage detection system (e.g. anti-spamming system), and ananti-spyware system. It should be noted that such security systems areset forth for illustrative purposes only, and that the client system 402may include any security systems capable of identifying informationassociated with unwanted activity. As an option, the security systemsmay be integrated, such that each security system may be incommunication with the other security systems on the client system 402.

The client system 402 also includes a database for storing data, such asrules, events, management instructions, objects, etc. In one embodiment,the rules stored in the database may be capable of being utilized by thesecurity systems for detecting unwanted activity. For example, the rulesmay indicate to the security systems which identified activity isunwanted. Optionally, the rules may be correlated utilizing policies. Inanother embodiment, the rules may be received by the client system 402from the central system 404.

Further, the events stored in the database may include data identifyingevents associated with the client system 402. For example, the eventsmay include execution of a process (e.g. downloading of content, etc.),execution of an application (e.g. device drivers, dynamic linklibraries, etc.), etc. Thus, the data may include a memory snapshot, aunique identifier (e.g. signature, etc.), version information, etc.associated with an event.

As an option, the events may be detected utilizing the security systemsof the client system 402. As another option, the events may be performedon the client system 402. Still yet, the objects stored in the databasemay include objects stored on the client system 402. Just by way ofexample, the objects may include files, applications, networkconnections, etc.

In addition, the management instructions may include instructions formanaging operations of the client system 402, such as the operations ofthe security systems. In one embodiment, the management instructions mayindicate the objects to be monitored by the security systems. In anotherembodiment, the management instructions may indicate functions to beutilized by the security systems for detecting unwanted activity,functions for preventing unwanted activity, functions for responding tounwanted activity (e.g. repair functions, removal functions, cleaningfunctions, etc.), etc. As another option, the management instructionsmay be utilized for managing the rules, events, objects, and/or anyother information associated with the client system 402.

In yet another embodiment, the management instructions may indicateinformation associated with unwanted activity detected at the clientsystem 402 that is to be sent to the central system 404. For example,the management instructions may indicate the information associated withevents, such as events associated with unwanted activity and/or wantedactivity, that is to be sent to the central system 404. As anotherexample, the management instructions may indicate whether informationassociated unwanted activity that has been detected and prevented is tobe sent to the central system 404. As an option, the managementinstructions may be received from the central system 404.

The client system 402 also includes functions for performing behavioralmonitoring, prevention, detection and repair of unwanted activity. Suchbehavioral monitoring may be utilized to monitor activity associatedwith the client system 402 utilizing heuristics, for example. In thisway, the client system 402 may be capable of detecting unwantedactivity, wanted activity (e.g. activity of wanted programs, etc.)without necessarily utilizing rules received from the central system404. In addition, the client system 402 may be capable of makingdecisions, such as optionally preventing and/or repairing detectedunwanted activity, without necessarily utilizing rules received from thecentral system 404.

In response to detecting unwanted activity, the client system 402identifies information associated with the unwanted activity utilizingthe security systems located on the client system 402. In oneembodiment, the client system 402 may identify the information based onthe rules stored on the client system 402. Of course, however, theclient system 402 may identify the information in any desired manner. Asshown, the information may indicate events associated with unwantedactivity, decisions made by the client system 402 (e.g. with respect toprevention, repair, etc. of unwanted activity), hashes of code utilizedby the unwanted activity, sources of unwanted activity, a time in whichunwanted activity was detected, etc. Similarly, the client system 402may also identify information associated with wanted activity.

As an option, the client system 402 may store the identified informationin the database. Further, the client system 402 determines whichidentified information to send to the central system 404. As describedabove, management instructions stored in the database may be utilizedfor determining the identified information to be sent to the centralsystem 404. Such identified information determined by the client system402 is thus sent to the central system 404. Optionally, the clientsystem 402 may correlate and/or format (e.g. normalize, etc.) theinformation prior to sending such information to the central system 404.

In response to receipt of the information associated with the unwantedactivity, and optionally wanted activity, from the client system 402,the central system 404 performs an action based on the receivedinformation. For example, the central system 404 may include rules fordetermining which action to perform with respect to the receivedinformation. The rules may be defined manually by users 410 (e.g. virusresearches, administrators, etc.), for example. The users 410 mayoptionally utilize any desired device for defining the rules.

In one embodiment, the action may include correlating the informationwith other information received by the central system 404, such asinformation received from a network security system 408, any otherclient system (not shown), etc. As an option, the information may becorrelated with information stored in a central database 406. Forexample, the information may be sent to and stored in any number of aplurality of central databases 406 with which the central system 404 isin communication.

Optionally, the central system 404 may manage the central databases 406.For example, the central system 404 may query the central databases 406,modify (e.g. populate, etc.) the central databases 406, set (e.g.configure, etc.) the central databases 406, etc. Further, the centraldatabases 406 may be populated with information received by the centralserver 404 from the client system 402, the network security systems 408,users 410, network crawlers (not shown), etc.

The central databases 406 may include a web site reputation database forstoring information associated with reputations of particular web sites(e.g. information indicating web sites known to be associated withunwanted activity, etc.). In addition, the central databases 406 mayinclude a vulnerabilities database for storing information associatedwith system and/or network vulnerabilities determined to be exploitableby unwanted activity. For example, the vulnerabilities may be associatedwith the client system 402, the network security systems 408, etc.

Further, the central databases 406 may include a firewall database forstoring rules for filtering activity. The central databases 406 may alsoinclude an anti-phishing database and a database associated withunsolicited electronic messages (e.g. shown as an anti-spam database).Such anti-phishing database and anti-spam database may store rules fordetermining, respectively, whether activity includes phishing activityand/or unsolicited electronic messages. Any rules indicated by thefirewall database, anti-phishing database and anti-spam database may becommunicated to the associated security systems of the client system402, via the central system 404, for example.

Still yet, the central databases 406 may include a risk and compliancedatabase for indicating whether devices in communication with thecentral system 404 (e.g. the client system 402, network security systems408, etc.) are in compliance with predetermined policies. The centraldatabases 406 may further include a black list database for storinginformation (e.g. signatures, etc.) indicating known sources of unwantedactivity, along with content, binaries, web sites, etc. known to beassociated with unwanted activity. In addition, a white list databasemay store information (e.g. signatures, etc.) indicating sources ofwanted (e.g. legitimate, etc.) activity, as well as content, binaries,web sites, etc. known to be associated with wanted activity.

Also, the central databases 406 may include a reports database forstoring reports generated based on unwanted activity that has beendetected. Of course, however, the reports may also be generated based onany information stored in any of the other central databases 406.Optionally, the reports database may also store real time and/or offlinerules generated by a reporting engine.

Moreover, the central databases 406 may include a rules database forstoring rules capable of being utilized by security systems of theclient system 402, the network security systems 408 and/or the centralsystem 404. Just by way of example, the rules may include operationalrules for the central system 404 regarding correlating information,reporting information, etc. As another example, the rules may beutilized for automation associated with unwanted activity.

The central databases 406 may additionally include an events databasefor storing information identifying events associated with detectedunwanted activity, and optionally wanted activity. For example, theevents database may store information associated with unwanted activitydetected by the client system 402, the network security systems 408,unwanted activity automation systems (not shown), etc. Of course, asanother option, the events database may store information manuallygenerated by users 410.

Furthermore, the central databases 406 may include an objects databasefor storing management instructions capable of being distributed to thedevices in communication with the central system 404. For example, themanagement instructions may indicate which objects are to be monitoredfor unwanted activity. The objects database may also store informationassociated with objects (e.g. processes, files, registry entities,network connections, etc.) managed by the client system 402, objects[e.g. electronic mail servers, web servers, web sites, unsolicitedelectronic message servers, transmission control protocol/internetprotocol (TCP/IP) connections, user datagram protocol/internet protocol(UDP/IP) connections, peer-to-peer (P2P) protocol connections, riskmanagement states, etc.] managed by the network security systems 408,object relationships [e.g. a file downloaded from a web site, anapplication of the client system 402 and a distributed denial of service(DDoS) attack, a group of client systems that initiated a particularnetwork attack, etc.], etc. Optionally, the events database and/or theobjects database may be utilized for providing complete information on ahistory of unwanted activity associated with a network on which thecentral system 404 is located.

In another embodiment, the action performed by the central system 404may include processing the information received from the client system402. The processing may include analyzing the information. Just by wayof example, the analysis may verify whether the unwanted activityassociated with the information is in fact unwanted, and optionallywhether wanted activity associated with the information is in factwanted.

In yet another embodiment, the action may include sending a response tothe client system 402 and/or any of the network security systems 408.Such response may be based on the information received by the centralsystem 404. For example, the response may include a rule for detectingfuture instances of the unwanted activity, a rule for removing codeutilized by the unwanted activity, etc. As another example, the responsemay include a rule for a rule (e.g. including a fingerprint of thewanted activity) for allowing instances of the wanted activity. Thus,the rule may be added to rules utilized by the client system 402 and/orany of the network security systems 408, such as a blacklist of rulesassociated with unwanted activity and/or a whitelist of rules associatedwith wanted activity. It should be noted that any rule sent to theclient system 402 and/or any of the network security systems 408 maysimilarly be stored at the central system 404.

In still yet another embodiment, the action may include generating areport associated with the information. For example, the report mayutilize data stored in the reports database to generate the report.Further, such report may be sent to the client system 402 and/or any ofthe network security systems 408.

In yet another embodiment, the action may include notifying a user 410of the information associated with the unwanted activity. Thenotification may include an electronic message, for example. As anoption, the notification may request the user 410 to perform a manualanalysis with respect to the information associated with the unwantedactivity. Of course, it should be noted that the above actions capableof being performed by the central system 404 in response to receipt ofthe information are set forth for illustrative purposes only, and thatany desired action may be performed by the central system 404.

Moreover, as described above, the central system 404 is in communicationwith a plurality of network security systems 408. In the context of thepresent embodiment, the network security systems 408 may include anydevices utilized for providing network security. In one optionalembodiment, the network security systems 408 may be provided by a singlesecurity system provider. As another option, the network securitysystems 408 may be provided by multiple security system providers. Asshown, the network security systems 408 may include a securitycompliance system, a web security system, a risk management system, anetwork intrusion prevention system, an electronic mail security system,etc.

To this end, the central system 404 may be in communication with theclient system 402 and the network security systems 408 for sendingupdates (e.g. dynamically, etc.) to such client system 402 the networksecurity systems 408. In one embodiment, the updates may include anyinformation, such as rules, policies, white list information and/orblack list information (e.g. hashes of web sites, applications networkpackets, scripts, etc.), etc. to the client system 402 and the networksecurity systems 408. As an option, the updates may include informationfrom the central databases 406. The updates may also include informationreceived from other devices on the network. For example, informationreceived from the client system 402 may be sent as an update to thenetwork security systems 408, and vice versa.

Furthermore, the central system 404 may receive updates from the clientsystem 402 and/or the network security systems 408. For example, theupdates may indicate events detected via the client system 402 and/orthe network security systems 408, decisions (e.g. repairs, prevention,etc.) made by the client system 402 and/or the network security systems408, etc. To this end, the central system may be capable of receivinginformation, rules, decisions, alerts, etc. associated with multipledifferent security systems located on various devices on a network.

In one exemplary embodiment, the client system 402 may identify anapplication that is acting as spyware, utilizing a security systemlocated on the client system 402. The client system 402 may thus reportthe application to the central system 404. For example, the clientsystem 402 may send information indicating the application is spyware tothe central system 404. In response to receipt of the information fromthe client system 402, the central system 404 may store the informationin a central events database 406.

Further, the central system 404 may receive a report from a networksecurity system 408 of a packet that has been sent over a network fromthe spyware application of the client system 402. Such report mayindicate the particular sent packet. The central system 404 may thencorrelate the packet with the application in the central events database406.

In another exemplary embodiment, the client system 402 may include anetwork browser which is utilized to access a web site. Upon a requestto access the web site via the client system 402, the client system 402may send information, such as a uniform resource locator (URL) to thecentral system 404 indicating the access request. The central system 404may query a central black list database/central white list database 406with the URL for determining whether the URL is included in such centralblack list database/central white list database 406.

The results of the query are then sent to the client system 402. Thus,if the URL is for a web site known to be associated with unwantedactivity (e.g. if the URL matches an entry in the central black listdatabase), the client system 402 may block the access to the web site.For example, such access may be blocked via a firewall of the clientsystem 402.

FIG. 5 shows a method 500 for reacting to an event, decision and/oralert, in accordance with yet another embodiment. As an option, themethod 500 may be carried out in the context of the functionality andarchitecture of FIGS. 1-4. Of course, however, the method 500 may becarried out in any desired environment. Again, it should also be notedthat the aforementioned definitions may apply during the presentdescription.

As shown in operation 502, at least one event, decision, alert, etc. isreceived from a network server and/or a client system, at a centralsystem. For example, information on an event associated with unwantedactivity detected on the client system may be sent to the central systemby the client system. As another example, a decision made by the clientsystem regarding how to react to the detected unwanted activity may alsobe sent to the central server by the client system. As yet anotherexample, an alert may be sent to the central server by the networkserver (e.g. network security system, etc.) for notifying the centralserver of information associated with unwanted activity.

Additionally, the received event, decision, alert, etc. is correlatedwith information stored in a database, as shown in operation 504. In oneembodiment, the central system may populate the database with thereceived event, decision, alert, etc. Such database may include acentral database remotely located with respect to the central system, asan option. As another option, the database may include a database storedon the central system.

In another embodiment, the received event, decision, alert, etc. may becorrelated by storing the received event, decision, alert, etc. in anassociated database (e.g. a database storing similar information, etc.).For example, if an event was received, the event may be stored in anevents database. In another embodiment, the received event, decision,alert, etc. may be correlated by storing the received event, decision,alert, etc. in a portion of the database that includes informationassociated with the received event, decision, alert, etc. Just by way ofexample, if an event is received, the event may be stored in a portionof the database that stores information associated with such event (e.g.such as a similar event that was previously detected, etc.).

Furthermore, at least one rule is identified and pushed to the networkserver and/or the client system, as shown in operation 506. In oneembodiment, the rule may be identified utilizing a central database. Forexample, the central system may query a central rules database for arule associated with the received event, decision, alert, etc.Optionally, the central system may utilized any portion of the receivedevent, decision, alert, etc. (e.g. such as a source that initiated anevent, etc.) for querying the central database to identify the rule. Inanother embodiment, identifying the rule may include generating the ruleutilizing the central system, based on the received event, decision,alert, etc.

In addition, the rule may be pushed to the network server and/or theclient system in any desired manner. In one embodiment, the rule may bepushed to the device from which the event, decision, alert, etc. wasreceived. Thus, if the client system sent the event, decision, alert,etc. to the central system, the rule may be pushed to the client system.Of course, however, the rule may also be pushed to the network server ifthe event, decision, alert, etc. was received from the client system.

In this way, the client system and/or network server may be updated withthe rule. Optionally, the central system may determine whether theclient system and/or network server have the rule stored thereon, priorto pushing the rule to such client system and/or network server.Accordingly, the rule may be prevented from being pushed to a device(i.e. client system and/or network server) on which the rule is alreadylocated.

Still yet, the network server and/or the client system react based onthe rule. Note operation 508. For example, if the client system receivedthe rule, the client system may react based on the rule. Likewise, ifthe network server received the rule, the network server may react basedon the rule.

In the context of the present embodiment, the reaction may includeperforming any operation that is based on the rule. Just by way ofexample, the reaction may include executing the rule, determiningwhether the rule is violated by the event, decision, alert, etc. sent tothe central system, storing the rule in a database, verifying theaccuracy of the rule, etc.

Moreover, the network server and/or the client system send an alert tothe central system, as shown in operation 510. Optionally, the alert maybe sent in response to the reaction performed by the network serverand/or the client system. Thus, in one embodiment, the alert may includeresults of the reaction performed by the network server and/or theclient system. For example, the alert may indicate whether the rule isvalid, whether an event violated the rule, etc.

FIG. 6 shows a system 600 for sending information associated withunwanted activity from a central system to a super system, in accordancewith still yet another embodiment. As an option, the system 600 may beimplemented in the context of the functionality and architecture ofFIGS. 1-5. Of course, however, the system 600 may be implemented in anydesired environment. Again, it should also be noted that theaforementioned definitions may apply during the present description.

As shown, a first client system 602 is in communication with a centralenterprise system 604. In the context of the present embodiment, thecentral enterprise system 604 may include a system managed by anenterprise, such as a central server of a LAN, for example. Accordingly,the first client system 602 may optionally be in communication with thecentral enterprise system 604 via an enterprise network.

The first client system 602 may identify events associated with unwantedactivity utilizing a plurality of different security systems located onsuch first client system 602. The first client system 602 may also makedecisions associated with such events, issue alerts associated with suchevents, etc. Further, the first client system 602 may send identifiedevents, decisions, alerts, etc. to the central enterprise system 604.

Additionally, the central enterprise system 604 may react based onreceived events, decisions, alerts, etc. In one embodiment, the centralenterprise system 604 may send updates (e.g. rules, policies, etc.) tothe first client system 602. For example, the central enterprise system604 may access data stored in central enterprise databases 606, forcommunicating such data to the first client system 602.

The central enterprise system 604 is also in communication with networksecurity systems 608. The network security systems 608 may be providedby a security system provider, for example, for securing the enterprisenetwork. Thus, the network security systems 608 may secure datacommunicated over the enterprise network, devices located on theenterprise network, etc.

Furthermore, the central enterprise system 604 is in communication withusers 610, such as virus researchers, administrators, etc. Such users610 may include users of the enterprise network, for example. The users610 may receive information from the central enterprise system 604, suchas information sent to the central enterprise system 604 by the clientsystem 602 and/or the network security systems 608. In this way, theusers 610 may manually analyze the information, in one embodiment. Theusers 610 may also communicate information to the central enterprisesystem 604, such as data with which to populate the central enterprisedatabases 606, requests for data from the central enterprise databases606, etc.

Moreover, the central enterprise system 604 is in communication with asuper system 614. The super system 614 may include a system utilized forsending and/or receiving information with respect to other second clientsystems 612A-B, other users 618, other central databases 616, etc. As anoption, the super system 614 may be located on a network different fromthe enterprise network, such as for example, the Internet. In this way,the super system 614 may communicate with devices located on a networkdifferent from the enterprise network. Optionally, the super system 614may be managed by the security system provider.

The second client systems 612A-B may identify events associated withunwanted activity utilizing a plurality of different security systemslocated on such second client systems 612A-B. The second client systems612A-B may also make decisions associated with such events, issue alertsassociated with such events, etc. Further, the second client systems612A-B may send identified events, decisions, alerts, etc. to the supersystem 614.

Additionally, the super system 614 may react based on received events,decisions, alerts, etc. In one embodiment, the super system 614 may sendupdates (e.g. rules, policies, etc.) to the second client systems612A-B. For example, the super system 614 may access data stored insecurity system provider central databases 616, for communicating suchdata to the second client systems 612A-B. Such security system providercentral databases 616 may be managed by the security system providerthat manages the super system 614, for example.

As shown, the super system 614 may also be in communication with asecurity system provider threat automation system 620. The securitysystem provider threat automation system 620 may be utilized forsecuring the network on which the super system 614 is located. Forexample, the security system provider threat automation system 620 maycommunicate automation tasks to the super system 614 for instructing thesuper system 614 which operations to execute. As another example, thesecurity system provider threat automation system 620 may configure,modify, query, etc. the security system provider central databases 616.

Furthermore, the super system 614 is in communication with users 618associated with the security system provider, such as researchers,administrators, etc. The security system provider users 618 may receiveinformation from the super system 614, such as information sent to thesuper system 614 by the second client systems 612A-B. In this way, thesecurity system provider users 618 may manually analyze the information,in one embodiment. The security system provider users 618 may alsocommunicate information to the super system 614, such as data with whichto populate the security system provider central databases 616, requestsfor data from the security system provider central databases 616, etc.

Still yet, the central enterprise system 604 is in communication withthe super system 614. In this way, the central enterprise system 604 andthe super system 614 may optionally exchange rules, events, decisions,alerts, etc. received by client systems 602, 612A-B, network securitysystems 608, etc. For example, such exchange of information may allowcentral systems of different networks to communicate informationassociated with unwanted activity detected on such networks. As anoption, the super system 614 may manage the central enterprise system604 and the second client systems 612A-B, such as by sending managementinstructions to the central enterprise system 604 and the second clientsystems 612A-B, for example.

As another option, the super system 614 and the central enterprisesystem 604 may be hierarchically arranged. For example, the centralenterprise system 604 may only disclose information to devices locatedon the enterprise network, such as the client system 602, the networksecurity systems 608 and/or the central enterprise databases 606.Similarly, the super system 614 may optionally only disclose informationto devices on its network, along with the central enterprise server 604.In this way, data (e.g. confidential data, etc.) communicated within thecentral enterprise system 604 may be protected from disclosure outsideof the enterprise network.

Just by way of example, the central enterprise system 604 may includecategorization rules for identifying levels associated with information.In one embodiment, the categorization rules may be user defined. Thecentral enterprise system 604 may apply the categorization rules toreceived information for determining a level of the information. Invarious embodiments, the information may be associated with a singlelevel or multiple levels. The information may thus conditionally becommunicated to the super system 614 based on the level of theinformation, as an option.

FIG. 7 shows a method 700 for configuring a device, in accordance withstill yet another embodiment. As an option, the present method 700 maybe carried out in the context of the functionality and architecture ofFIGS. 1-6. Of course, however, the method 700 may be carried out in anydesired environment. Yet again, it should also be noted that theaforementioned definitions may apply during the present description.

As shown in operation 702, a first profile associated with a device isidentified. In the context of the present embodiment, the device mayinclude any device located on a network. For example, the device mayinclude a client system. In one embodiment, the first profile may beidentified in response to detection of the device. For example, thefirst profile may be identified upon a connection of the device to anetwork.

In addition, the first profile may include any characteristicsassociated with the device. In various embodiments, the first profilemay include applications installed on the device, network connections ofthe device, hardware of the device, etc. As an option, the first profilemay be identified utilizing a central system in communication with thedevice. For example, the central system may request information from thedevice that indicates the characteristics of the device. Of course, asanother example, the central system may query a database for the firstprofile of the device.

Furthermore, a second profile associated with a network is identified,as shown in operation 704. In one embodiment, the network may includethe network on which the device is located. In another embodiment, thenetwork may include the network on which both the device and the centralsystem are located. Optionally, the second profile may be identifiedutilizing the central system.

Moreover, such second profile associated with the network may includeany information indicating characteristics of the network. For example,the second profile may indicate a type of the network (e.g. LAN, WAN,etc.). As another example, the second profile may indicate any otherdevices located on the network capable of being in communication withthe device.

Still yet, rules are configured for the device based on the firstprofile and the second profile, as shown in operation 706. In thecontext of the present embodiment, the rules may include any policies,etc. capable of being utilized to by the device. In one embodiment, therules may include rules for determining whether activity is unwanted. Inanother embodiment, the rules may indicate operations to perform inresponse to the detection of unwanted activity.

Additionally, configuring the rules may include dynamically generatingthe rules. In another embodiment, configuring the rules may includeidentifying rules applicable to information included in the firstprofile and/or the second profile, in one embodiment. Just by way ofexample, rules applicable to an operating system of the device may beidentified for the device. As an option, a database of rules may bequeried for identifying the rules. Such query may utilize theinformation included in the first profile and the second profile, in oneembodiment. In another embodiment, the rules may be configured utilizingthe central system.

Moreover, the rules may be sent to the device, as an option.Accordingly, the device may store the rules (e.g. in a database, etc.),such that the rules may be accessible to the device. For example,security systems of the device may access the rules for processingvarious activity identified on the device by such security systems. Asan option, the rules of the device may be initially configured, forexample, upon the device connecting to a network on which the centralsystem is located. To this end, various devices in communication with acentral system may be configured with different rules, based on a deviceprofile and a network profile associated with each of such devices.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. Thus, the breadth and scope of a preferred embodiment shouldnot be limited by any of the above-described exemplary embodiments, butshould be defined only in accordance with the following claims and theirequivalents.

What is claimed is:
 1. A method, comprising: receiving one or more rulesfrom a central system; identifying information associated with unwantedactivity, utilizing a plurality of different types of security systemsof a client system, which includes a processor and a memory, and whichis configured with a plurality of rules for resolving the unwantedactivity independent of instructions provided by a the central system,wherein at least one of the different types of security systems utilizesbehavioral monitoring that includes heuristics of the unwanted activityto detect the unwanted activity without utilizing the one or more rules,and the client system is further configured to detect the unwantedactivity utilizing the one or more rules; sending the information to thecentral system for aggregating the information with additionalinformation sets provided by additional client systems; and receiving aresponse sent from the central system to the client system and to theadditional client systems, wherein the response is based on theinformation and is indicative of whether the information was verified asbeing associated with the unwanted activity, and wherein the responseincludes a rule for removing code associated with the unwanted activity,and the response includes a rule for detecting future instances of theinformation, and the response includes a rule for adding the informationto a blacklist.
 2. The method of claim 1, wherein the plurality ofdifferent types of security systems include two or more of a firewall,an intrusion prevention system, an anti-spyware system, and a virusscanner.
 3. The method of claim 1, wherein the information is correlatedprior to sending the information to the central system.
 4. The method ofclaim 1, wherein the information includes a source of the unwantedactivity.
 5. The method of claim 1, wherein the information includes adecision made in response to the unwanted activity.
 6. The method ofclaim 5, wherein the decision is to block execution of the unwantedactivity.
 7. The method of claim 1, wherein the information includes analert.
 8. The method of claim 1, further comprising detecting theunwanted activity, utilizing the plurality of different securitysystems.
 9. The method of claim 8, wherein the unwanted activity isdetected utilizing at least one rule received from the central system.10. The method of claim 1, wherein the information is sent to a databasevia the central system.
 11. The method of claim 1, wherein theinformation is sent to the central system for correlation with otherinformation associated with at least one network security system.
 12. Acomputer program product embodied on a non-transitory computer readablemedium for performing operations, comprising: receiving one or morerules from a central system; identifying information associated withunwanted activity, utilizing a plurality of different types of securitysystems of a client system, which includes a processor and a memory, andwhich is configured with a plurality of rules for resolving the unwantedactivity independent of instructions provided by a the central system,wherein at least one of the different types of security systems utilizesbehavioral monitoring that includes heuristics of the unwanted activityto detect the unwanted activity without utilizing the one or more rules,and the client system is further configured to detect the unwantedactivity utilizing the one or more rules; sending the information to thecentral system for aggregating the information with additionalinformation sets provided by additional client systems; and receiving aresponse sent from the central system to the client system and to theadditional client systems, wherein the response is based on theinformation and is indicative of whether the information was verified asbeing associated with the unwanted activity, and wherein the responseincludes a rule for removing code associated with the unwanted activity,and the response includes a rule for detecting future instances of theinformation, and the response includes a rule for adding the informationto a blacklist.
 13. An apparatus, comprising: a client system includinga processor, wherein the apparatus is configured forand a memory; andlogic that is executable by the processor for: receiving one or morerules from a central system; identifying information associated withunwanted activity, utilizing a plurality of different types of securitysystems of a the client system, which includes a processor and a memory,and which is configured with a plurality of rules for resolving theunwanted activity independent of instructions provided by a the centralsystem, wherein at least one of the different types of security systemsutilizes behavioral monitoring that includes heuristics of the unwantedactivity to detect the unwanted activity without utilizing the one ormore rules, and the client system is further configured to detect theunwanted activity utilizing the one or more rules; sending theinformation to the central system configured for aggregating theinformation with additional information sets provided by additionalclient systems; and receiving a response sent from the central system tothe client system and to the additional client systems, wherein theresponse is based on the information and is indicative of whether theinformation was verified as being associated with the unwanted activity,and wherein the response includes a rule for removing code associatedwith the unwanted activity, and the response includes a rule fordetecting future instances of the information, and the response includesa rule for adding the information to a blacklist.
 14. The apparatus ofclaim 13, wherein the processor remains in communication with the memoryand a display via a bus.
 15. The computer program product of claim 12,wherein the plurality of different types of security systems includestwo or more of a firewall, an intrusion prevention system, ananti-spyware system, and a virus scanner.
 16. The computer programproduct of claim 12, wherein the information is correlated prior tosending the information to the central system.
 17. The computer programproduct of claim 12, wherein the information includes a source of theunwanted activity.
 18. The computer program product of claim 12, whereinthe information includes a decision made in response to the unwantedactivity.
 19. The computer program product of claim 18, wherein thedecision is to block execution of the unwanted activity.
 20. Thecomputer program product of claim 12, wherein the information includesan alert.
 21. The computer program product of claim 12, wherein thecomputer program product is embodied on the non-transitory computerreadable medium for performing further operations comprising detectingthe unwanted activity, utilizing the plurality of different types ofsecurity systems.
 22. The computer program product of claim 12, whereinthe information is sent to a database via the central system.
 23. Thecomputer program product of claim 12, wherein the information is sent tothe central system for correlation with other information associatedwith at least one network security system.
 24. The apparatus of claim13, wherein the plurality of different types of security systemsincludes two or more of a firewall, an intrusion prevention system, ananti-spyware system, and a virus scanner.
 25. The apparatus of claim 13,wherein the information is correlated prior to sending the informationto the central system.
 26. The apparatus of claim 13, wherein theinformation includes a source of the unwanted activity.
 27. Theapparatus of claim 13, wherein the information includes a decision madein response to the unwanted activity.
 28. The apparatus of claim 27,wherein the decision is to block execution of the unwanted activity. 29.The apparatus of claim 13, wherein the information includes an alert.30. The apparatus of claim 13, wherein the apparatus is furtherconfigured for detecting the unwanted activity, utilizing the pluralityof different types of security systems.
 31. The apparatus of claim 13,wherein the information is sent to a database via the central system.32. The apparatus of claim 13, wherein the information is sent to thecentral system for correlation with other information associated with atleast one network security system.